都是脏数据惹的祸
“小光，今天那个诡异的生产环境问题找到原因了吗？”
“还是数据问题！之前做的一个功能有一部分数据迁移工作没有做好，导致生产环境有脏数据，委托人的联系人已经不为该委托人服务了，应该移除掉的…=-#~)@/-$*…”
“又是脏数据…@=@”
“嗯，好在不是代码问题。”
这是在蓝鲸项目发生的真实对话。其中提到的脏数据（Dirty data），也叫坏数据（Bad data），通常是指跟期待的数据不一样、会影响系统正常行为的数据。
蓝鲸项目的QA会定期分析生产环境的缺陷，当定位某个缺陷为脏数据引起之后，往往就到此为止了。生产环境下的缺陷分析流程是这样的：
调查分析生产环境缺陷，到最后定位是数据问题的时候，总是让人浑身轻松... 于是，“脏数据”就跟测试的“随机挂”一样，成为了光荣的“背锅侠”！
脏数据 ≠ 代码问题，真的是这样吗？先来深入了解一下脏数据。
脏数据是怎么回事？
脏数据产生的原因多种多样，有的甚至很难解释清楚到底发生了什么…
通常，以下原因可能造成脏数据：
脏读：读了事务处理中间状态的数据
重复插入了相同的数据：多次点击同一个按钮导致
不能为空的字段存为空：数据库字段没有验证，或者对于历史数据没有做好迁移处理
人工录入不合法的数据：比如电话号码含有特殊字符
运行SQL脚本插入了不合法数据：比如不同实体id搞混等
存入了多余的空格
测试环境可能由于部署了半成品产生一些不合法数据
……
因此，脏数据跟代码有关，脏数据的产生是因为没有做好防御工作！
脏数据有哪些危害？
根据不同的系统、不同的业务，脏数据带来的危害也会不一样。
脏读产生的数据往往是错误的，导致数据不真实性，或者数据的不一致性；
重复和其他不合法数据则可能导致系统行为的不正常，有时候还可能导致非常严重的故障，甚至有些没有暴露的脏数据可能带来不可预知的致命错误，危害可能是相当大的。
脏数据带来的危害很难估量，有很大的不可预测性，对于脏数据的预防至关重要。
那么，如何能够防范于未然呢？
如何预防脏数据的产生？
尝试对脏数据引起的生产环境缺陷做进一步分析，总结出脏数据的几种类型，可以在敏捷软件开发生命周期的不同阶段对其进行防御。
业务需求分析阶段
在业务分析的时候，根据业务需求，明确业务相关数据的特定要求：
不能为空的字段
不能重复的数据
日期范围
电话号码可以有“ext.”、“+”和“-” 但不能有其他字符
特殊字符的限定
功能升级的时候考虑已有数据的迁移
还有一些跟常识不同有特定业务含义的数据需求
……
数据库和代码实现阶段
明确了数据的需求，可以根据需求定义和软件使用常识，在实现层面对数据进行严格的约束和校验：
数据库表的主外键、字段类型、是否允许为空，事务处理隔离等
前后端对数据进行严格的校验，防止各种手段存入不合法的数据，包括需求定义的数据和常识性的数据，比如身份证号码最多18位等
考虑多用户同时处理可能带来的并发问题
防止按钮或者链接被重复多次点击，可重复点击通常在网速较慢时可能存入重复数据
程序读取数据的时候进行处理，比如去掉多余空格、去重、大小写不敏感数据的处理
……
测试的进一步保障
有了需求定义和实现层面的校验，大部分的不合法数据被阻止了，但是还是会有漏网之鱼，在测试的时候继续采取相应的措施来进一步防御。
业务需求规定的数据：这个毫无疑问是需要测试的，有底层的单元测试覆盖会更好
常识性的数据：由于不同的人可能有不同的常识，这些问题在测试的时候还需要特别关注
探索隐藏边界：关于隐藏边界的概念大家可能不是很熟悉。咱们通常说的等价类、边界值分析方法设计测试用例，都是根据可见的边界来考虑的，其实咱们程序后台可能还存在一些隐藏的边界，也是很有可能会导致数据问题的，需要在测试过程中进行探索发现它们并进行验证。
关于隐藏边界，可以参考John Ruberto的文章《Uncovering Hidden Boundary Values in Testing》，里边提到了四种隐藏边界：数据类型边界、信任域边界、特殊数据值、复活节彩蛋。除此之外，咱们平常测试过程中可以多积累，总结出还有哪些可能会导致数据问题的隐藏边界。
对线上用户的培训
做了前面一层层的防御，如果最终用户在使用的时候能够按照规范操作数据，对减少脏数据的产生会很有帮助。
下面两个措施可以培训用户更规范的操作数据：
在界面上给出清晰的提示，告诉用户某些数据输入的要求
给用户培训或者提供用户手册，告诉用户该怎么正确使用系统
如何处理已产生的脏数据？
有那么多预防脏数据产生的方法，但相信脏数据的产生还是在所难免的。脏数据一旦产生，导致的系统行为也是不可预测的，可能无足轻重，也可能暴露非常严重的缺陷。该如何应对产生的脏数据呢？
脏数据产生以后有两种存在形式，一种是已经引起某些问题被发现了，另一种是还不被人知道，不知道哪天会发生什么样的问题。
已经暴露的脏数据
对于已经暴露的脏数据，首要的是对数据的快速修复，让系统恢复正常运转。对于专业的脏数据处理可以了解一下数据清洗（Data cleaning）技术。咱们平常对于脏数据的修复，可以根据业务需求，采用数据库脚本修复，或者在前端执行JS脚本来修复。
修复数据需要特别注意不要引入新的脏数据，编写脚本之前要理清相关业务和数据之间的关系，编写好脚本之后要经过严格的测试才能在线上环境执行。
修复数据的同时，需要进一步调查数据产生的原因，检查可以在哪个环节加固防御措施，以尽量减少类似数据问题再次发生的可能性。
未暴露的脏数据
这样的数据，其实我们并不知道它的存在，就像一个在黑暗处的幽灵，不知道什么时候会给系统带来麻烦。
由于系统环境的复杂性、用户行为的多样性，生产环境更加容易产生脏数据。尽早发现这种潜在危害的脏数据非常重要。
蓝鲸项目就是这样。在跟客户做支持的同事沟通过程中，最大的担忧就是生产环境的数据总能发现问题，如何能够让这些问题尽早暴露出来？
推荐生产环境下的测试（Testing in production，TiP）的一些实践。
1. 直接在生产环境测试
生产环境是高度受保护的，不可以随意测试，以免破坏生产环境的稳定性。在生产环境写入数据要特别谨慎，大批量的读操作也要注意对系统性能的影响。
有些可以隔离出来的功能或操作，相对来说是安全的，可以在生产环境直接测试。比如，蓝鲸项目的邮件服务，常会在生产环境部署单独的服务器来测试。
需要根据项目真实情况去做决定。
2. 将生产环境数据清理后用于测试环境
生产环境数据含有PII（个人身份信息，需要保护的隐私信息）或者其他机密，通常不能直接用于测试环境。
将生产环境数据的PII和其他机密信息清除后用于测试环境，测试人员基于这些数据做测试，就能有效的提前去发现由于生产环境数据引起的问题。
这个方案很好，但是要权衡ROI。对于一些复杂的系统，数据库结构过于复杂，清理的成本太高，也是不太现实的。
3. 利用蓝绿部署等TiP实践
蓝绿部署是一种通过运行两个相同的生产环境“蓝环境”和“绿环境”来减少停机时间和风险的技术，是TiP非常典型的一个实践。
在任何时候，只有一个环境是活的，活的环境为所有生产流量提供服务。通常绿环境是闲置的，蓝环境是活的。部署新的版本到绿环境，可以先进行测试，而不会给真正在使用的蓝环境带来影响。完成部署和测试以后，再进行蓝绿环境的切换。
此技术可以消除由于应用程序部署导致的停机时间。此外，蓝绿部署可降低风险：如果新版本在绿环境上发生意外情况，可以通过切换回蓝环境立即回滚到上一版本。这样就有机会提前发现脏数据可能引起的问题。
类似的技术，还有金丝雀发布等，也有助于提前发现脏数据的问题。
写在最后
脏数据的防御是关键
这跟敏捷测试的质量内建原则是一致的。质量内建强调缺陷预防，在预防缺陷产生的同时，要加强对于脏数据的防御。根据敏捷测试的节奏，在敏捷开发生命周期各个环节做好脏数据的预防和处理工作，尽量减少脏数据给生产环境带来的危害。
如果由于各种原因防御工作不到位，脏数据产生后也要分析总结，回过头来指导开发环节的工作，进一步加强防御。
脏数据让我们又爱又恨
恨的是脏数据的产生总是会导致系统行为的不可预测，让系统质量保障变得复杂。尤其是一些脏数据不停的出现，还总是找不到原因的时候，很让人抓狂！总想到此为止，让脏数据来背锅。
但这不是明智的做法，脏数据都是有原因的，不挖掘出真正的原因，可能带来更加意想不到的后果。找出根因，做到防微杜渐，才是正道。
爱的不是因为脏数据可以帮我们背锅，而是它的存在可以帮助我们暴露程序潜在的问题，是做好系统质量保障工作、生产环境下的QA不可或缺的助手。
QA朋友们，请加强对脏数据的重视，善待脏数据！
如果对本文引用文章资料感兴趣，请点击“阅读原文”查看更多详细内容。